home *** CD-ROM | disk | FTP | other *** search
/ Whiteline: Alpha / Whiteline Alpha.iso / progtool / modula2 / granule / storbase.doc < prev    next >
Encoding:
Text File  |  1994-09-22  |  4.1 KB  |  78 lines
  1. (*########################################################################
  2.                               S T O R B A S E
  3.   ########################################################################
  4.  
  5.   Idee          : Johannes Leckebusch, Peter Sollich
  6.   Realisation   : Peter Sollich
  7.   Dynamic Heap  : Peter Hellinger
  8.  
  9.   ########################################################################
  10.  
  11.   28.05.89 Hp   deallocate ist jetzt in der Lage nur ein Teil-Deallocate
  12.                 des Speicher-Blocks durchzuführen. 
  13.  
  14.   26.05.89 Hp   Problem des "doppelten Lottchens" in deallocate gelöst.
  15.                 Stürzt nun nicht mehr bei bereits deallozierten Pointern ab.
  16.  
  17.   28.12.88 Hp   deallocate stürzt nicht mehr bei NIL-Pointern ab.
  18.            +    Allozierungs reihenfolge verändert. Dadurch das "Heaprest"-
  19.                 Problem gelöst. Siehe auch Kommentar in allocate.
  20.            +    Berechnung der freien bzw. belegten Bytes im Heap auf Bytes
  21.                 umgestellt. free liefert jetzt auch die Anzahl freier BYTES.
  22.            +    memAvail liefert nun die Anzahl aller freien BYTES sowohl
  23.                 im Heap, als auch im noch nicht allozierten Speicher - 
  24.                 abzüglich der GEMDOS-Reserve von 64kb (Konstante GEMReserve)
  25.            +    In AppendHeap wird nun bei JEDER Fehlerbedingung das Dynamic-
  26.                 Flag FALSE geschaltet. (!!)
  27.                 
  28.   04.12.88 Hp   Initalisierung des Heaps beschleunigt.
  29.                 Markierung von Lisp-Blöcken durchgängig gemacht; läuft nun
  30.                 auch über AppendHeap.
  31.  
  32.   03.12.88 Hp   Zu früh gefreut: Storage läuft nicht. Warum? Nach endlosem
  33.                 Debugging habe ich zwei Fehler gefunden:
  34.                 1. Die Größe des Blocks der per AppendHeap angefordert
  35.                    wurde, wird nicht richtig gesetzt. Dadurch ist die
  36.                    Blockberechnung von DEALLOCATE katastrophal falsch.
  37.                    Warum es zunächst funktionierte ist mir schleierhaft.
  38.                 2. GEMDOS.Alloc liefert nicht NIL wenn kein Speicher mehr
  39.                    da, ist sondern NULL. AppendHeap konnte deshalb das
  40.                    Ende des Speichers nicht erkennen.
  41.  
  42.   28.11.88 Hp   Initialisierung für GESAMTEN Speicher eingeführt. Kann 
  43.                 sonst zu Problemen führen wenn wir Blocks bekommen die
  44.                 nicht durch unsere freeMap abgedeckt werden.
  45.  
  46.   25.11.88 Hp   Bug in allocate beseitig. allocate testet nun BEVOR es nach
  47.                 einem Block sucht, ob der Heap überhaupt groß genug ist.
  48.                 Der G2E läuft jetzt einwandfrei. Damit müßten eigentlich
  49.                 alle schwerwiegenden Fehler behoben sein.
  50.  
  51.   23.11.88 Hp   Jubel! Heaptest lief einwandfrei! 3640 x 1000 Byte und an-
  52.                 schließend 1820 x 2000 Byte. Nun kommen die Härtetests.
  53.  
  54.   22.11.88 Hp   Heute fiel der Groschen: Es ist wieder einmal eines jener
  55.                 Dinge, die einem fast in die Nase zwicken, bevor man sie
  56.                 sieht. Also: Wir tarnen das Stückchen Speicher, daß wir
  57.                 in den Heap integrieren wollen als von ALLOCATE behandlet
  58.                 (korrekt gesetzte Größen, GranulesUsed richtig berechnet etc.
  59.                 largeSentinel erhält die neue Heapgröße) und lassen es von
  60.                 DEALLOCATE in den Heap integrieren... Physikalisch zusammen-
  61.                 hängende Speicherbereiche werden anhand der BitMap ermittelt
  62.                 und als größerer Block in den Heap integriert.
  63.  
  64.   20.11.88 Hp   Versuchsweise Implementierung von AppendHeap -> Bombenstimmung
  65.  
  66.   19.11.88 Hp   freeMap wird bei Modul-Initialisierung für den ganzen verfüg-
  67.                 baren Speicher angelegt -> dadurch Weg frei für eine dynamische
  68.                 Heap-Erweiterung.
  69.  
  70.   18.11.88 Hp   Massenweise Kommentare ergänzt.
  71.                 Bezeichner etwas entkryptisiert...
  72.                 Standard-Initalisierung bei Aufruf von ALLOCATE (@#!)
  73.  
  74.   08.08.87      Johannes Leckebusch / Peter Sollich
  75.                 Erstimplementation
  76.  
  77.   ########################################################################*)
  78. ə